---

Block Puzzle

Similar to last month's Slide Puzzle, this month's Block Puzzle creates and captures the sprites within the program. To minimize flickering, a small graphicbox is opened while the sprites are being created and loaded. That graphicbox is then resized to the larger, desired size using the locate and refresh commands. For the sake of this program, there are 3 defined areas where the sprites can be displayed and manipulated.

1. The notYet Area is the lower and far right portion of the screen where the block sprites first appear. In this area, each block piece can be rotated into the desired orientation.

2. The Active Block Area is a transition spot. Once the block sprite has been rotated into the correct orientation , the Active Block Area holds the selected piece for placement into the grid. In the Active Block Area, the block piece awaits being dragged into place in the puzzle box.

3. The Grid Area is the puzzle box itself. The block sprite is dragged into place using mouse down, move, and up commands. The program uses a formula derived from the column and row to determine the x,y cords that will 'snap' the block into place.

The program takes advantage of the spritescale command to display the same sprites in 3 different sizes. The sprites in the notYet Area are displayed at the original size ["spritescale ";block$(block);" 100"]. Once taken to the Active Block Area and Grid Area, the same sprite is displayed at double the original size ["spritescale ";block$(block);" 200"]. A menu option allows the user to view all the sprites. These sprites are displayed at ¼ the original size ["spritescale ";block$(block);" 25"].

Sprites can be rotated to 180° using the spriteorient command. There is, however, no command for 90° or 270° orientations. The program must create and load a sprite for each possible orientation, one, two, or four. The data statements contain the number of the sprite to be used next when that sprite is to rotated.

The program is fully directed by mouse movements. The commands are

• when leftButtonDown

• when leftButtonMove

• when leftButtonUp

• when rightButtonUp

By careful manipulation of these mouse event commands, the program allows action at desirable places only. For instance, the program starts with all block sprites in the notYet Area. Any mouse clicking that takes place in either the Active Block Area or the Grid Area is ignored, until a block sprite is moved to the Active Block Area. Once one block sprite has been moved to the Active Block Area, any L-clicking from the notYet Area or R-clicking from the Grid Area is ignored. To quickly review the when leftButtonUp command,

#w.g, "when leftButtonUp [LselectBlock]" directs the program to code following [LselectBlock]

#w.g, "when leftButtonUp" directs the program to do nothing on L-click, essentially disabling mouse L-click.

Left, right, up, down, move, over commands follow the same scheme.

A final note regarding Liberty BASIC v3.03 vs Liberty BASIC v.4.0: Liberty BASIC v.4.0 contains a spritetofront command which is not available in v3.03. When the block sprite is being dragged from the Active Area to the Grid Area, the program checks to see which version of Liberty BASIC is being used:

if val(Version$) >= 4 then
    #w.g, "spritetofront ";block$(block)
end if

Version 3.03 will show the sprite being dragged 'behind' other sprites, while version 4.0 shows a much nicer display of the block sprite out in front.

There is no one solution to any puzzle. To check for a winning solution, the program keeps track of the assigned number of the block sprite which fills each column,row cell. Since the program does not allow illegal placements (e.g, a piece of the block extending beyond the border of the puzzle grid), then anytime a check finds every cell is filled (or <> 0), the puzzle has been successfully solved.

---

Ring Puzzle

This is my first attempt at using an API call. I'd like to thank Alyce Watson for making MaskMaker.bas available to study. The Liberty BASIC help document "API and DLL Calls" included with Liberty BASIC v3.03 (which I suspect Alyce also had a hand in) was also invaluable in this endeavor. I am always amazed at the quantity and quality of the free code made available in the Liberty BASIC package. Truly, the more I learn, the more I appreciate these snippets. Secondly, I'd like to thank Brad Moore for his excellent article The Beginner's Guide to API and DLL Calls (Liberty BASIC Newsletter 101).

Like Slide Puzzle (Liberty BASIC Newsletter #117) and Block Puzzle, Ring Puzzle is another mindless solitaire game. [I tend to dispute the "mindless" part.--Ed]

Ring Puzzle uses simple colorfilled commands. There are no sprites in this program. The puzzles start out in solution order. The rings are then randomly turned clockwise or counterclockwise to "mix up" the beads.

During the initial shuffling routine, and then with each user turn of a ring, the GDI Get Pixel call is used to determine the 'new' color of the beads of adjoining rings. The circles are then redrawn with the correct colors. As with any program using graphics, careful attention must be paid to "discard" and "cls" commands to conserve memory.

I hope you get some enjoyment with these puzzles. I certainly enjoyed creating them. Although none of the puzzles create random designs, it is an easy matter to add to the data statements of any of the three programs.

Happy Programming!

---